Tom,

OK, no prob. Either of those could be a good way to go in the long run, but would require more hardware and software changes than I care to get into right now. For now, I think I can make do with the existing port. The pendant is Rx-only to the KFlop, and I can make the ATC Tx-only, with a single dedicated "Done" signal back to KFlop through an I/O.

BTW - I have the ATC working very nicely now, with the control code running on KFlop, and it's integrated with my app and KMotion. It's done many hundreds of tool changes, with just a very few very minor mechanical hiccups, that I think are now all fixed. I hope to use it to cut metal for the first time in the next few days.

Regards,
Ray L.

--- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@...> wrote:
>
> Hi Ray,
>  
> No I don't think a software UART would work very well especialy attempting to receive async data.
>  
> You might consider something like multiple slaves on the one serial port.  We do now have ModBus code that runs in KFLOP if that would help.  It is included in the V4.30e test release.  See the C:\KMotion430e\C Programs\RS232\ModBus directory.
>  
> Regards
> TK
>
>
>
> ________________________________
> From: himykabibble <jagboy@...>
> To: DynoMotion@yahoogroups.com
> Sent: Monday, October 22, 2012 9:56 PM
> Subject: [DynoMotion] Software UART
>
>  
> Tom,
>
> Do I recall seeing a software UART somewhere? I'd like to have a second serial port (the first is dedicated to my pendant, and I'd like to put the ATC on a second one, to reduce I/O usage on KFlop). This one need not be high speed. Obviously, writing a software UART is trivial, but how to deal with the variable task timing in user threads? If a software UART is not practical, I suppose my fallback would be to use a 2- or 3-wire protocol (SPI, I2C, etc).
>
> Regards,
> Ray L.
>